Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / 92mar / bgpisis-minutes-92mar.txt < prev next >

Wrap

Text File | 1993-02-17 | 11.3 KB | 261 lines

These Minutes should be considered a rough draft only - Megan 04/03/92 ============================================================================== Notes from BGP WG - San Diego IETF - 3/19/92 9am [David Bolen - db3l@ans.net] ============================================================================== * Discussion of BGP-4 Extensions The largest portion of the BGP meeting was concerned with the discussion of the BGP4 document authored by Vince Fuller and Tony Li. The additions were made primarily to add the necessary support into BGP for classless inter-domain routing (CIDR). * IP Prefixes vs. Masks The need for carrying some form of network masks as part of BGP was discussed in the light of the need for classless inter-domain routing (CIDR). The necessary information could be carried either as a combination of network and netmask, or it could be encoded as a prefix with a length value. A key difference between the two proposals is that carrying an entire mask allows the use of non-contiguous masks, while a prefix requires that the mask be contiguous. The general consensus of the group was that non-contiguous masks presented several problems, especially in routing table lookups (where multiple entries can match), and in the automatic aggregation of such masks (which we aren't sure how to do yet, and it's critical for CIDR). Therefore prefixes, being more deterministic, were a better choice for BGP-4. It was agreed that masks could prove useful later when some of the trickier issues have been dealt with. In that case, they could always be added to a later version of the protocol. >> Use prefixes rather than masks. * Aggregation rules from BGP-4 document The group discussed the various rules presented in the BGP-4 document to handle aggregation: * Rule 1 - always do longest match. * Rule 2 - Inject "poison" routes to avoid loops. In a multi-homed case, if the aggregator is the primary provider, the aggregator must also announce the longer prefix for the client (to override the same announcement via that client's other provider). If the aggregator is not primary, this additional announcement is not necessary. * Rule 3 - Punch hole to sever old route when switching providers. This requires an announcement withdrawal mechanism in BGP. In particular, rule 3 was discussed in that it required the addition of a withdrawal mechanism in BGP to withdraw a previous announcement (along the lines of the facility provided within IDRP). The largest concern if this wasn't provided was that packets could flow partially down a bad path before they were either bounced or black-holed. Also, traceroute would no longer function properly in such a case. The general consensus was that these problems were not critical enough to warrant the added complexity of the withdrawal mechanism, especially when interoperability with older implementations of BGP that didn't have such a mechanism was taken into account. >> Rules 1 & 2 ok - removing Rule 3. * Support for AS sets In order to be able to handle multi-level aggregation, the ability to specify an AS_PATH that included AS sets rather than simply a sequence is very important. If AS-1 and AS-2 both flow packets through AS-3, AS-3 would like to be able to aggregate routes if AS-1 and AS-2 fall under the same prefix. Since they represent different AS_PATHs, that is currently not possible. IDRP was brought up as an example of using sets. In IDRP, the RD_PATH (like BGP's AS_PATH) is an overall sequence of elements, where each element is either an RD sequence, or an RD set. An RD set implies that the packets flow through one or more of the RDs in the set, but not necessarily all of them, and no order is specified. IDRP also provides for the concept of routing confederations, which is a method for aggregating several routing domains into a single routing domain confederation (RDC) which is generally treated just like an RD when it appears in the RD_PATH. Using confederations was considered more powerful than just sets, but also more complicated, and not required for the CIDR support we want to include in BGP-4. A possibility was just to turn BGP's AS_PATH into a set, which would imply no particular order of AS traversal. However, this would prevent any route filtering based on AS order. Matt Mathis suggested having an AS_PATH that started with a sequence, and was followed by a set. This discussion also brought up the fact that the AS_PATHs would probably be growing as this structure would encourage the size of an AS to be small, which led to thinking about the assignment of AS numbers hierarchically in order to allow them to be aggregated as well. Finally, the discussion turned to whether AS values should be increased to 32-bit rather than 16-bit. Some people strongly felt it should be increased in size, especially now as we were making these other changes. >> General consensus for requiring sets/sequences, but not confederations. Stick with 16-bit AS, although moving to 32-bit at the same time as the AS set change was strongly discussed. * Parallel BGP sessions During the discussion, the issue of being able to run parallel BGP sessions turned out to primarily address the problem of wanting to filter on an AS wherever it shows up in the AS_PATH, rather than just the first AS (as is common in current applications). This is an implementation problem rather than one with the protocol. The point was made that it can be dangerous to run two BGP connections in the same host with the only exchange of information between them being a routing table handled through a common IGP. Therefore, it was decided that it wasn't worth changing the protocol to handle what was essentially an implementation issue. >> Dropped * NEXT_HOP Handling The NEXT_HOP discussion centered around the issue of allowing one BGP peer to pass along the address of some other host on a common wire as the NEXT_HOP value rather than using its own address. The knowledge that the other host was available would commonly have been determined via an IGP (such as OSPF), or by the fact that the BGP peer was maintaining sessions with both hosts. Yakov brought up IDRP as an example of this functionality but under control of the source, which can choose to add additional options to a NEXT_HOP announcement controlling whether the recipient can propagate the NEXT_HOP value. This addresses the multiple BGP session, but not the IGP case. The concern with allowing this optimization was that the new host was being included in the NEXT_HOP announcement without it being aware of its involvement. Under certain circumstances this can be very useful, but it can also easily violate policy or routing rules. It deserved some further investigation, but for now (and at least for BGP-4), it was decided to keep the current definition of NEXT_HOP. >> Keep definition/use same as is currently specified. * BGP/OSPF Interaction Document A short discussion of the current BGP/OSPF interaction document by Kannan Varadhan took place. The document is nearing completion, and only had a few changes since the previous IETF. * Tag bits If the upper ("trusted") bit of the tag is set, the tag was system generated or configured, and the following 3 bits are used to encode the completeness of the route and how it should be handled, as follows: pl 00 01 10 11 c 0 <EGP> <l> <EGP><l,nh> never export reserved 1 <IGP> <l> <IGP><l,nh> out of band reserved Matt Mathis suggested that the term "trusted" may not be the most appropriate (it could be taken to imply that the network administrator isn't trusted). Tony Li suggested the substitution of the term "automatic" instead. >> Change "trusted" keyword to something like "automatic". * NEXT_HOP handling with subnets This issue dealt with an optimization for handling the case where you learn a set of routes through OSPF that represented an entire subnet for a network, and what to assign NEXT_HOP to in that case. The optimization in question was whether or not you still had to always place yourself in NEXT_HOP rather than the node through which the subnets were routed. It was agreed that this represented an implementation optimization and should not be dictated by this document, but left to the choice of the developer. >> Leave optimization to developers. A new revision of the document will be published with a fairly short deadline for comment, so that the document can then proceed through the standards process. * IBGP & OSPF Discussion Jeff Honig held a discussion about possible problems with the use of IBGP, and how the same information might be propagated through an IGP (specifically OSPF) rather than with IBGP connections. The main concerns with IBGP were the need for scaling of N^2 connections, and the bandwidth utilized for IBGP traffic. Enhancements to OSPF that were being discussed to be used to carry the external information included: - OSPF Variable Tags (to allow the encoding of a complete AS_PATH) - New OSPF Path Attribute LSA to propagate path/attribute pairs (to send unique path/attribute information around in separate packets that were referenced by the route announcements) During the discussion, the general feeling was that the difference between IBGP resource usage (N-1 TCP connection blocks on each border router (BR), and bandwidth) and the resource required to distribute the same information via an IGP was not significantly different. Also, trying to store external information in internal routers could cause physical resource problems (such as memory) for those routers. One agreed issue with IBGP was router discovery. Using the IGP to aid the BRs in discovering each other was considered an important feature. At a minimum, all that would be required is a single flag bit to be carried by the IGP to indicate that a host was a BR. Ideally several bits to encode additional information would be useful. >> General discussion felt that IBGP resource utilization was not significantly more than that introduced by having the IGP carry EGP information. >> Agreement was reached that border router discovery was important and that some bits (at least 1) should be requested from IGPs such as OSPF to support this. * BGP <-> IS-IS Interaction Document Sharad Sanghi held a discussion on the BGP/IS-IS interaction document that he and Atul Bansal had authored. The general issues were similar to the BGP/OSPF interaction document. The basic question discussed was in regards to the advantages and disadvantages to doing route injection vs. piggybacking vs. just using IBGP. As with the previous IBGP vs. IGP (OSPF) discussion, the group felt that it was not clear that the savings in resources by eliminating IBGP and using IS-IS to carry external routing information was worth the work to transfer the routes. Router discover was still very useful, so adding bits to IS-IS (which it already has room to support) is definitely desired. Using IBGP with these bits for discovery should be fine for stub domains. For transit systems, it could prove useful to consider the injection/piggybacking cases, which should be studied further.